Field
The described embodiments relate to computing devices. More specifically, the described embodiments relate to handling critical sections in program code in computing devices.
Related Art
In some computing devices, one or more instructions in program code may be grouped into what is called a “critical section.” Generally, critical sections include instructions that are intended to be prevented from being concurrently executed with the instructions in one or more other critical sections (including, in some cases, other instances of a critical section itself). For example, when instructions from a first section of program code are to access memory without the values in the accessed memory locations being changed while the instructions from the first section are executed by instructions from a second, third, etc. section of program code, critical sections may be used to prevent the instructions from the second, third, etc. sections of program code from changing the values. As described, this can include preventing the instructions from the first section from being executed concurrently by two entities (e.g., cores, threads, etc.) in the processor (as two separate instances of the first section).
Each critical section is associated with (or “protected by”) a lock that is intended to prevent the instructions in the critical section from being executed concurrently with the instructions in other critical sections that are protected by the same lock. When a given entity in a processor acquires the lock for a corresponding critical section, the given entity is able to freely execute the instructions in the critical section. However, other entities are prevented from simultaneously acquiring the lock and thus are unable to execute any critical section protected by the same lock.
A lock is often acquired by the given entity when the given entity transitions a value of a lock variable for the lock from a first value indicating the lock is free (a FREE value such as 0) to a second value that indicates that the lock has been taken (a TAKEN value such as 1). For example, in some cases, a critical section comprises a lock-acquisition instruction, one or more instructions to be executed, and a lock-release instruction. In existing processors, when executing a critical section, an entity in the processor first executes the lock-acquisition instruction. The lock-acquisition instruction causes the entity to write the TAKEN value to the lock variable. The entity then executes the one or more instructions from the critical section. After executing the one or more instructions from the critical section, the entity executes the lock-release instruction, which causes the entity to release the lock by writing the FREE value to the lock variable.
Using critical sections as described can result in unnecessary restrictions on the execution of program code. For example, an executing entity may execute a critical section that does not perform operations for which the results are externally “accessible” (i.e., accessible by other entities in the processor, such as performing writes to memory locations that are accessible to other entities in the processor, changing processor state that is accessible to other entities in the processor, etc.). In this case, the critical section's effect on the processor is isolated to the entity and preventing other critical sections from executing concurrently with the critical section unnecessarily restricts the execution of program code. Such restrictions can result in sub-optimal performance for the processor.
Throughout the figures and the description, like reference numerals refer to the same figure elements.